I think we need to also support filtering per name/value pair. So that you can control buffering based on things like cluster name or region.

Would cluster name and region be key-value pairs that are varying within the same process? Based on the names those sound like properties that would be fixed at process startup and remain constant throughout. This means all the decision making could occur at startup time when defining the filter rules rather than a decision that needs to be made per-log message later on. For example could you satisfy the scenario with some startup code like this?

logging.AddBuffering(buffering =>
{
    string region = GetRegionFromConfig();
    // in the test region we want to buffer some log messages that won't be buffered
    // in other regions
    if(region == "TestRegion")
    {
        buffer.AddFilter("ExperimentalFeatures");
    }
    ...
});

I'm not opposed to other things, I'm just trying to better understand what the scenario is.

Is this casting more performant than just formatter(attributes, exception)?

This loses log entries if another thread enqueues more of them between _buffer.ToArray() and _buffer.Clear(). That is more likely to happen on .NET Framework, where clearing the queue takes more time.

Moved the _lastFlushTimestamp update to the top, so that when a flush operation is initiated at one thread, another thread will skip buffering for some period of time because of the non-zero value of SuspendAfterFlushDuration option. Don't expect someone to set it to zero because it does not make sense to emit some buffered logs and buffer other at almost the same time.

IIRC, IOptionsMonitor<TOptions>.CurrentValue throws if the option is bound to configuration and the binding fails (parsing fails or a validator rejects the value); this could even happen when an operator modifies a configuration file after the application has already started. The BackgroundService would then fail and, depending on HostOptions.BackgroundServiceExceptionBehavior, either log buffer truncation would stop working or the whole application would terminate. Should this instead keep using the previous value of the options in that case?

This makes sense, but I will take another look at it later on, possibly after finalizing public API. Keeping this open until then

This allocates a closure and a delegate for each ILogger.Log<TState> call. I can think of two ways to minimize the allocations:

• Instead of serializedRecord.Attributes, pass serializedRecord itself as the state to ILogger.Log<TState>. Implement IReadOnlyList<KeyValuePair<string, object?>> in SerializedLogRecord by calling the corresponding methods of public IReadOnlyList<KeyValuePair<string, string>> Attributes.
• Alternatively, keep using the same delegate across all iterations of both foreach loops; declare the serializedRecord variable and a delegate variable before the outer loop. That way, it would allocate only one closure and one delegate per BufferSink.LogRecords call, no matter how many log records are in IEnumerable<T> serializedRecords. This is safe because ILogger.Log<TState> is not allowed to save the formatter delegate for later calling.

makes sense for optimizations later, thank you

This code moved from BufferSink to BufferedLoggerProxy in d7661a6. The BufferedLogRecord instances are not pooled, so each BufferedLogRecord call costs at least one allocation per BufferedLogRecord; that may make the delegate and closure allocations less important.

Please add DebuggerDisplayAttribute so that the list of log records in a buffer can be viewed more easily.

Or add the DebuggerDisplayAttribute to SerializedLogRecord, instead.

It might be more efficient to leave Filter as null and not call the filter in that case. I expect that most rules won't have a filter specified and the null check will be well predicted by processors. It would also make rules easier to understand in a debugger as actual filters would stand out better.

Are there any callsites where Filter is invoked with a null category string, null log level, or null EventId? If yes thats a little surprising but fine as long as we define what that would mean. If no then those parameter types don't need to be nullable.

await next(context).ConfigureAwait(false); 
}

This is the spot in the middleware where I would expect the majority of logging would occur. Right now it looks like the example code would not buffer that common case logging.

This would have to be obj.Value?.ToString(), in order to be consistent with Equals.
Alternatively just throw NotImplementedException, if this is designed to be used only with Enumerable.Contains, which doesn't call GetHashCode anyway.

"further"

This should have docs about what happens if a log entry matches a rule, and what happens if the log entry does not match any rule.

• Is the log entry discarded, buffered, or written directly to underlying loggers?
• Does it cause other log entries to be flushed from the buffer to underlying loggers? If so, does that apply to all log categories or only to the same category?

Alternatively, if this type is used with different semantics in different contexts, then document the behaviour in HttpRequestBufferOptions.Rules and GlobalBufferOptions.Rules, and link to those docs from here.